HTTPS: Add an HTTPS Endpoint
We'll cover the following
Adding the HTTPS endpoint#
We will now update our deploy-infra.sh
script to retrieve the certificate ARN. This should go at the top of the script, and depends on the DOMAIN
environment variable.
Line #3: Newly added environment variable holding our certificate.
We then have to pass the certificate ARN as a parameter to main.yml
.
Line #13: The certificate ARN.
We also have to add this as a parameter in the main.yml
template.
Then, we also have to pass the ARN to our nested stacks by adding a parameter to the Staging
and Prod
resources in main.yml
.
Line #11 and #23: The certificate ARN.
Finally, we have to add an input parameter in stage.yml
to receive the certificate ARN from main.yml
.
Next, we’re going to modify our security group to allow traffic on HTTPS ports 443 and 8443.
Line #12 and #20: Newly added HTTPS ports.
At this point, we need to modify the UserData
section of our EC2 launch template to make the instance generate a self-signed certificate automatically when it starts up. This certificate will be used for traffic between the load balancer and the instance.
Line #21: Generates a certificate (cert.pem
) and private key (key.pem
) and puts them in /home/ec-user/app/keys
.
Next, we add a new target group so that the load balancer forwards traffic to the application’s 8443 port.
Line #5: 8443 is the non-privileged port that our application will use to serve HTTPS requests.
Line #9: The health check will also be made on the HTTPS port.
Now, let’s add a new load balancer listener for HTTPS.
Line #9: The certificate ARN.
Line #10: 443 is the standard HTTPS port.
Then we need to add the new HTTPS target group to the ScalingGroup
ASG so that the instances managed by the ASG will be added automatically behind the load balancer’s HTTPS target.
Line #3: References the new HTTPS target group.
Next, we will also add a new entry to the Outputs
section in stage.yml
to return the URL for our new HTTPS endpoint.
Finally, we’ll add two new outputs from main.yml
for the new HTTPS endpoints.
Line #17: Newly added HTTPS endpoints.
It’s time to deploy our changes. This change may take longer than previous updates, because it has to spin up two new instances per stage with the updated launch script, and then terminate the old ones.
Our HTTP endpoints should continue to respond correctly. However, if we try to reach the new HTTPS endpoints, we’ll get an error, because the load balancer can’t yet reach our application on port 8443.
If you were to look for the new HTTPS target group in the AWS console, you should see no healthy hosts in the Monitoring tab. You can also see that the EC2 instances are being continuously created and destroyed.
This is happening because we haven’t yet updated our application to serve HTTPS requests on port 8443, so our instances are failing their health checks. In the real world, it would have been better to update the application first, and only then update the infrastructure. But here, we wanted to do it in the reverse order to demonstrate the behavior of the load balancer health checks. So, let’s push our infrastructure changes to GitHub, and then let’s fix our application.
Note: All the code has been already added and we are pushing it on our repository as well.
/
- deploy-infra.sh
In the next lesson, we will make our application speak HTTPS.